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(57) Abstract 

A method of transmitting a message over a netwoik from a sender to a receiver, comprises the steps of: taking a message (Cow) to 
**f ta ?y *f • me message into a digital signature (e. y) of the sender (steps 56, 58). the digital signature being generated 

i 'i J!?" . mcssa « e mhx * P ub,ic and secret signature generators (*. r) of the sender, a private key (j) of the sender, and other 
publicly known values (a, p. q); and transmitting the signed message over the network to roe receiver (step 60); characterised in that the 
^ tS ^ e \ <0 }l S>Sn , V thc . scnder »«orporates a first value (fix)) which is a first predetermined function (such as a secure one-way hash 
function) of the sender s public signature generator « (step 48). Its is thus possible that the incorporation of a proper first value can be 
i?? £aZ reCe '!! r ° thc . m " sagc wh0 ^ ins me sendtl » «8» message using a public signature generator, and furthermore that 
it a senaer signs and transmits the same message more than once, the private key of the sender can be derived from the plurality of signed 
messages and a relationship between the public and private signature generators. 
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Transmitting messages over a network 

Technical Fielri 

This invention relates to a method of and apparatus for transmitting messages over a 
5 network, and in particular, but not exclusively, is concerned with "cash purchases" 
over a network such as the Internet. 

Baclfpm Mnf f Aft 

Today, the business potential of the Internet, especially, of the world-wide-web 
10 applications, forms a new dimension in electronic commerce. It is believed that 
information purchases will form a very big part of the activities in the Internet 
electronic commerce. A typical nature of this form of commerce is to deal with a 
large volume of low-value payment transactions. The usual price for a few 
information pages can be as low as several cents. Various techniques proposed for 
15 macro payments are not suitable to be used here as transaction fees may well exceed 
the value of payments. Furthermore, these techniques do not preserve a proper 
purchaser's anonymity which can be an essentially important feature in information 
purchases. On the other hand, the vast diversity of the Internet information services 
(e.g. web-based services) means that the subscription-based services may not be very 
20 attractive to a large number of one-off viewers. It is thus reasonable to consider 
facilitating information purchases over the Internet with a cash-like payment 
^ instrument. 

Chaum's invention of the blind signature technique (patent document US-A-4759063) 
25 sets an important milestone for cash-based electronic commerce. After Chaum's 
original idea, the subject of electronic cash has been widely studied and many 
techniques proposed to tackle various unsolved problems. Real systems have also 
been implemented for trial use. However, when considering information purchases 
over the Internet, these previous techniques have various limitations 

30 

Firstly, an evident limitation in various previous off-line digital cash techniques is the 
high system complexity. In some of these techniques, a coin will have too big a data 
size to be economically used (containing a large number challenge terms for detection 
of cheating); some also require using complex challenge-response interactions 
35 between the payer and payee for each coin spent (a non-cash feature); others critically 
rely on using tamper-resistant devices (expensive smartcards with a built-in observer 
to monitor transactions). Systems relying on smartcards also have a limitation in 
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quick deployment over the Internet as most home/office computers today are not 
readily equipped with a smartcard reader. In some of the smartcard cash techniques, 
the built-in observer works itself without co-working with the cardholder's private 
key. Such techniques are potentially dangerous as compromising one smartcard 
5 devastates the whole system. Further, considering a fundamental principle of 

cryptography that a re-usable key with a limited length must have a limited lifetime, 
then systems using a system-wide observer also pertain to a high running cost due to 
the need of changing the observer in the system-wide devices from time to time. 

10 Secondly, schemes using on-line banks, though they can prevent double spending 
(each coin is checked against replay during the time of payment) rather than merely 
detect it afterwards (yet still with a good anonymity service) are obviously not 
suitable for micro-payments. Here, the problem is not only in terms of economy, but 
also system performance. Banks are far too few compared with the vast number of 

15 small cash transactions; by processing on-line requests for such transactions, they are 
doomed to becoming serious system bottlenecks. 

The present invention is concerned with enabling one or more of these problems to be 
solved, and it will be shown that an example of the invention can solve most, if not 
20 all, of these problems. 

Disclosure of Invention 

In accordance with a first aspect of the present invention, there is provided a method 
of transmitting a message over a network from a sender to a receiver, comprising the 

25 steps of: taking a message (Coin) to be signed by the sender; signing the message into 
a digital signature (e, y) of the sender, the digital signature being generated as a 
function of that message using public and secret signature generators (x, r) of the 
sender, a private key (s) of the sender, and other publicly known values (a, p, q); and 
transmitting the signed message over the network to the receiver; characterised in 

30 that: the message to be signed by the sender incorporates a first value (f(x)) which is 
a first predetermined function (such as a secure one-way hash function) of the 
sender's public signature generator (x). 

It is thus possible that the incorporation of a proper first value can be verified by a 
35 receiver of the message who requires the sender to sign the message using a public 
signature generator, and furthermore that if a sender signs and transmits the same 
message more than once, the private key of the sender can be derived from the 



-3- 

plurality of signed messages and a relationship between the public and private 
signature generators. 

The signature preferably includes a second value (e) which is a second predetermined 
5 function (h( )) (such as a secure one-way hash function) dependent on the first value 
(f(x)). 

The signature preferably includes a third value (y) which is a third predetermined 
function of the secret signature generator (r), the second value (e), the private key (s) 
10 of the sender, and at least one (q) of the publicly known values. 

The message to be signed by the sender preferably incorporates a fourth value (g(v)) 
which is a fourth predetermined function (g( )) (such as a secure one-way hash 
function) of a public key (v) of the sender. 

15 

This latter feature may be provided independently of the first aspect of the invention. 
Therefore, in accordance with a second aspect of the present invention, there is 
provided a method of transmitting a message over a network from a sender to a 
receiver, comprising the steps of: taking a message (Coin) to be signed by the sender; 

20 signing the message into a digital signature (e, y) of the sender, the digital signature 
being generated as a function of that message using public and secret signature 
generators (x, r) of the sender, public and private keys (v, s) of the sender, and other 
publicly known values (a, p, q); and transmitting the signed message over the 
network to the receiver; characterised in that: the message to be sighed by the sender 

25 incorporates a fourth value (g(v)) which is a fourth predetermined function (g( )) 
(such as a secure one-way. hash function) of the public key (v) of the sender. 

In accordance with a third aspect of the present invention, there is provided a method 
of verifying a signed message received over a network, the signed message 

30 purporting to have been transmitted in accordance with the method of the first aspect 
of the invention, comprising the steps of: calculating an apparent public signature 
generator (z) of the sender using the signed message, a public key (v) of the sender 
and other publicly known values (a, p); calculating a fifth value (f(z)) which is the 
first predetermined function (f( )) of the apparent public signature generator (z); and 

35 comparing the fifth value (f(z)) with the first value (f(x» incorporated in the received 
signed message. 
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In the case where a second value as defined above is expected in the received signed 
message, preferably the verifying method includes the further steps of: calculating a 
sixth value (e) which is the second predetermined function (h( )) of the fifth value; 
and comparing the sixth value (e) with the second value (e) included in the received 
5 signature. 

In the case where a fourth value as defined above is expected in the received signed 
message, preferably the verifying method includes the further steps of: calculating a 
seventh value (g(v)) which is the fourth predetermined function (g( )) of a public key 
10 (v) of the sender received over the network; and comparing the seventh value (g(v)) 
with the fourth value (g(v)) incorporated in the signed message. 

This latter feature may be provided independently of the third aspect of the invention. 
Therefore, in accordance with a fourth aspect of the present invention, there is 

15 provided a method of verifying the public key of the sender of a signed message 
received over a network, the signed message purporting to have been transmitted in 
accordance with a method according to the second aspect of the invention, comprising 
the steps of: calculating a seventh value (g(v)) which is the fourth predetermined 
function (g( )) of the public key (v) of the sender received over the network; and 

20 comparing the seventh value (g(v)) with the fourth value g(v) incorporated in the 
signed message. 

The invention also encompasses apparatus which is adapted to perform any of the 
methods described above. 

25 

Brief Description of Drawings 

A specific embodiment and examples of the invention will now be described, by way 
of example, with reference to the accompanying drawings, in which: 

30 Figure 1 is a schematic diagram of a sender's computer showing the setting-up 
of various parameters, common to the prior art and the embodiment of 
the invention; 

Figure 2 is a schematic diagram of a sendees computer showing steps taken in 
35 the prior art to send a message; 

Figure 3 is a schematic diagram of a receiver's computer showing steps taken in 
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the prior art to verify a received message; 

Figure 4 is a schematic diagram of a Bank's computer showing steps taken in 
the embodiment of the invention to supply a Coin; 



Figure 5 is a schematic diagram of a sender's computer showing steps taken in 
the embodiment of the invention to pay the Coin to a receiver; and 

Figure 6 is a schematic diagram of a receiver's computer showing steps taken in 
the embodiment of the invention to verify a received Coin. 



Best Moot, for Carrying Out the Invention *, in dustrial A rr i j r ^n i r y 

In an example of the invention described below, an off-line micro-cash technique is 

15 set out which is suitable for purchasing information (and other) services over the 
Internet. A number of cash features will be supplied. These include: purchaser's 
anonymity, identifying a double spender with strong proof, using no on-line banks 
for payment, being independent of using tamper-resistant devices, and providing a 
coin sub-divisible to arbitrary denominations (an important feature suitable for a 

20 single page information purchase). The main goal is to supply these services at a very 
low cost affordable by the system in accordance with the typically low values of 
per-payment transactions. This goal is achieved by the system simplicity in terms of 
small data size for representing coins (a payment of an arbitrary amount can be sent 
in less than one kilobyte), and in terms of no need of interactive communications 

25 between purchaser and merchant (a payment can be made in a single email). 

Taking a pragmatic approach to spender's anonymity, the anonymity service in the 
example of the invention is'Based on a trust that public-key certification authorities 
(CA's) do not collude with system suppliers (banks). Such a collusion will give a 

30 bank a cheap way to link each coin with its spender. Collusion between a bank and 
merchants can also defeat the anonymity service. However, it will be seen that, 
unless the collusion is on a large scale and therefore very costly for a bank, it will 
have a very limited extent of damage to the spender's anonymity. Nevertheless, such 
a pragmatic, low-cost anonymity service is appropriate to the system. From the 

35 system suppliers' point of view, low-cost is essential considering the low values of 
typical transactions. Even from the consumers' point of view, it is believed that this 
weak sense of anonymity will be acceptable by many users as they will regard the 
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convenience of securely sending money over the Internet to outweigh the extremely 
small probability of collusions between a bank and a CA, or between a bank and a 
vast number of merchants. People's attitude toward sending money over the Internet 
is expected to change. For instance, sending a few cents or a couple of dollars over 
5 the Internet will no longer be considered as "dangerous** as sending one's credit-card 
number (even encrypted). 

Similar to all other off-line cash techniques, a double spender will be identified after 
a double spending has occurred. However, a unique feature in the after-the-fact 

10 identification is that the identification is in terms of discovering the double spender's 
private key by the bank. Such a result of identification is effective in the following 
scenario. The bank can simply show the double spender's private key to the 
appropriate public-key certification authority; the associated public-key certificate can 
then be revoked instantly and unconditionally. Thus, no matter how small an amount 

15 of money (even a single penny or cent) is double spent, there are no possibly 

expensive legal requirements for the bank to process regarding the revocation of the 
certificate in question. This identification method is therefore particularly suitable for 
micro-payment transactions. The method also strongly deters double spending: a new 
certificate for a new pair of public/private keys for an identified double spender can 

20 be made sufficiently expensive that the price far outweighs the benefit of double 
spending low-value coins. 

The identification technique to be described uses a variation of Schnorr's signature 
scheme. Given a data in a certain format, exactly only one signature can be made on 
25 the data. Making more than one signature on the same data will lead to disclosure of 
the private key that is used for generating the signatures and for proving the identity 
of the signer. 

Firstly, a description will be given of Schnorr's original scheme (patent document 
30 US-A-4995082), with reference to Figures 1 to 3. As a public-key crypto-algorithm, 
Schnorr's signature scheme has a pair of public/private keys. In Schnorr's scheme, 
users in the whole system can share some public values as part of their public keys. 
First, choose two primes, p and q. Here, p is a large prime (e.g. p > 2 512 ) such that 
the discrete logarithm problem in Z* is intractable; q is also a large prime (e.g. 
35 q > 2 140 ) and q\ (p-1). Then, choose a number a e Z p * with order q (q is the smallest 
prime number satisfying 1 (mod p)\ such an a can be computed as the ip-\)Iq th 
power of a primitive element modulo q). It will be assumed that all parties in the 
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system share these numbers. 

To generate a particular public-key/private-key key pair, a prospective purchaser, 
herein called "Alice", chooses a random number less than q in step 12. This is her 
private key, s. Then, in step 14 calculate: 

v = a' s (mod p) (1) 

where v is Alice's public key. 



Schnorr's signature scheme uses a secure one-way hash function. Let h( ) denote a 
secure one-way hash function. It should be computationally infeasible to find two 
input values x *x' such that h(x) = h(x'); also with respect to the input, the output 
from h() behaves like an oracle, in that one cannot generate an expected output value 
15 by algorithmically manipulating the input values. 

To make a signature on message m, Alice picks a random number r, less than q (step 
16), and does the following computations: 

20 Step 18 x = (<f modp) (2) 

Step 22 e = h(m, x) (3) 

Step 24 y = ((r + se) mod </). (4) 

The signature on the message m is the pair e, y. We will call the other two numbers, 
25 r and x, "secret signature generators" and "public signature generators", (or SSG, 
PSG), respectively. In step 26, Alice sends the signature to a merchant, herein called 
"Bob." Bob verifies the signature by computing: 



Step 34 z = (aV mod p) (5) 

and checking if 

Step 36 e = h(m, z). 

35 If the equation holds, in step 38 he accepts the signature as valid. 



Schnorr's signature scheme gets its security from the difficulty of calculating discrete 
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logarithms. The difficulty means that the private key s cannot be easily derived from 
the public key v even with their relationship shown in Equation (1). Similarly, the 
secret signature generator (SSG) r cannot be easily derived from the non-secret 
number z from their relationship in Equation (2) (z is equal to the public signature 
5 generator (PSG) x). 

Besides relying on the difficulty in computing discrete logarithms, the security of the 
one-way hash function h( ) also plays an important role in Schnorr's scheme. This 
security derives from the difficulty in preparing input data that maps to a given output 

10 value, or to find two input data that collide to the same output value. When Bob 
verifies the signature, he knows from the property of the hash function that, without 
knowing Alice's private key, it is computationally infeasible to create the consistency 
among the numbers e, y, z and m which are related under the hash function used. The 
hash function h( ) is essentially an oracle; it is difficult to prepare input data that map 

15 to a given output value. 

Note that the SSG r must be treated as one-time material. It must not be used more 
than once to generate different signatures. Assume otherwise, an SSG r has been used 
before by Alice in a signature on some message m and now Alice re-uses it to 

20 generate a new signature on a different message m \ Let e and y be the numbers used 
by Bob during the verification of the signature on m f and e\ y' be those that 
correspond to the new message m\ Now that m' * m, from Equation (3) and the 
property of the hash function we know almost for sure (with an overwhelming 
probability) that e' * e (mod q). If these non-secret numbers (e, y) and (e\ y') are 

25 acquired by Bob, he can compute Alice's private key s by subtracting two instances 
of Equation (4) and obtain: 

5 » ((y - yy(e - e') modq) (6) 

30 On the other hand, as long as Alice does not repeat using any old SSG when creating 
a new signature, then subtraction of Equation (4) will only result in y - y 9 s r - r' + 
s(e - e') (mod 7). Here the value r - r' * 0 (mod q) remains to be a secret that 
protects the private key s just in the same way as in Schnorr's scheme. More 
precisely, Alice should not use an SSG which is related to an old SSG in any known 

35 algorithmic way. As long as this precautionary measure is taken, no arithmetic 
calculation is known so far that allows one to derive the signer's private key from 
different instances of signature values. In fact, the digital signature standard (DSS) 
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proposed by NIST uses essentially the same principle to protect the signer's private 
key. 

The example of the invention employs the property illustrated in Equation (6) to 
5 identify a user who has used certain data more than once, and the identification can 
be supported with a strong proof. The idea is to create a consistent relationship 
between a piece of data to be signed (a condition for using the data) and a PSG (x or 
z in Schnorr's scheme) used for making the signature. In other words, let Alice 
(signer) sign a piece of data, and let Bob (signature verifier) be provided with a 
10 method to know that, for the data in question, Alice has used a required PSG (and 
hence its correspondent SSG, see below). If a wrong PSG has been used, then Bob 
will not accept the signature even if it is valid under the usual usage of Schnorr's 
scheme. 

15 Note that it is impossible for Alice to find two SSG's r* r' (mod q) that map to 
PSG's satisfying x=x' (mod/>). Being able to do so would allow Alice to sign the 
same data twice without disclosing her private key. This is because from x*x' 
(modp), i.e. d s <f (mod/>), we have oT' s l (mod /?); but a has order q which 
means q is the smallest non-zero number satisfying a 1 = l (mod p), so it has to be the 

20 case that r=r' (mod q). 

This idea finds a good application in designing an electronic cash technique in 
accordance with the invention. A double spender of a coin will be identified with a 
strong proof whereas honest users enjoy their anonymity. Below there follows a 
25 description with reference to Figures 1 and 4 to 6 of an example of simple cash coin 
in accordance with the invention which has this property obtained from using a 
variation of Schnorr's scheme. 

Let Alice have a coin constructed as a result of her cash withdrawal from a bank (not 
30 necessarily from her own bank). The coin has been digitally signed by the bank to be 
worth a certain amount of value, and this can be validated by any receiver of the coin 
(with the use of a public-key certificate authority, CA). The bank's signature on the 
coin follows Chaum's blind signature technique. The coin is blinded in that, once 
Alice has completed the withdrawal, the bank then loses any link between the coin, 
35 and the withdrawer, Alice. For conciseness, in this specification, a description of the 
known anonymous cash, withdrawal procedure based on using the blind signature 
technique has not been included, but reference is directed to patent document 
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US-A-4759063. 

During the withdrawal time, the coin is constructed such that it integrates a pair of 
one-way hashed values,^), g(v). The first value is mapped from a PSG x chosen by 
5 Alice, and the second from the Alice's public key v. Note that the whole withdrawal 
process need not use Alice's public key v at all. This is because the bank need not 
check the correctness of these two hashed values. Later it will be seen that Alice will 
be wasting her money if she integrates incorrect values into a coin. 

10 Let Sig B be the bank's blind signature. We can denote a coin as follows: 

Ste P 4 * Coin = Sig B (C,fix), 

Here C is called a "coin pseudonym", which is recognisable as a bank coin by any 
15 receiver who can verify the bank's blind signature. In Schnorr's scheme, a pair of 
SSG, PSG can be pre-computed. So there will be no problem for Alice to prepare 
PSG x (and the respective SSG r) during the withdrawal time. 

When Alice pays Coin to a merchant, she is required to sign the pseudonym C using 
20 the PSG x integrated in Coin. Herein this signature is called a "spending signature". 
The spending signature on C should include the merchant's identity and a timestamp 
stating the spending time. Namely, the message to be signed (m in Equation (3)) 
becomes: 

25 C, merchant Jd, timestamp. 

The spending signature uses a variation of Schnorr's original scheme: the value e will 
be computed by the following equation different from the original form in Equation 
(3), namely: 

30 

Step 56 e = h(C, merchant Jd, timestamp, J{x)) (7) 

In this variation, a hashed valued) is used, rather than directly using x as in the case 
of the original Schnorr's scheme (cf Equation (3)). It will be shown below that this 
35 variation will prevent the bank from discovering Alice's public key (when Alice does 
not double spend). In order to let the merchant verify the spending signature, Alice 
should also send her public key v together with a valid key certificate to the 
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merchant. Let Cert(X f K) be a public-key certificate issued by a well-known CA 
certifying the public key K to the principal X, and let U X - Y: message" denote that 
the principal X sends the message to the principal Y. The payment message will be 
seen as follows: 

5 

Payment: Alice - Merchant: Coin, merchant Jd, timestamp, e, y, 

Cert(Alicejd, v) 

Here, the value y is computed by Alice as in Equation (4), see step 58. The merchant 
10 will verify the spending signature using Alice's public key v. He first uses the values 
e, y, a, v to compute z as in Equation (5), see step 62. Then, he verifies if Equation 
(7) holds by using f(z) in place of f(x)> see step 64. He also checks the correct use of 
the PSG x and the public key v. The two correct uses mean that z and v can be hashed 
using/( ) and g() to the respective two hashed values in Coin, as shown in steps 66, 
15 68. The payment will not be accepted if an incorrect PSG or public key is used, 
because the merchant will have trouble in redeeming an incorrectly signed coin. 

Later, the merchant will redeem the coin by depositing the following "coin deposit* 
data to the bank: 

Deposit: merchant - Bank: Coin, merchant Jd. timestamp, E(z), e t y (8) 

Here, E(z) denotes that the merchant encrypts the value z with the public key of CA. 
Note that using a CA's public key for encryption seems to add a new role for CA's. 
25 However, it will be seen later that this is a measure to detect a rare case of double 
spending (rare because it is that the double spender colludes with a merchant)* Note 
that when a double spending occurs, a CA will be approached anyway in order to 
revoke the key certificates of those responsible. From this point of view, no 
essentially new role will be added to CA's. 

30 

The merchant must digitally sign the coin deposit. The signature not only means that 
the merchant has properly dealt with the payment, but also serves to prevent the bank 
from altering the data. 

35 There now follows an analysis of the operation of the scheme described above. First, 
assume that Alice does not double spend her coins. Then her anonymity of spending 
the coins will be protected. This is because the coin-deposit in Equation (8) does not 
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contain any information about spender's identity. Note that the anonymity here is in a 
sense that the merchant does not collude with the bank. It suffices for the merchant to 
be non-collusive if he just throws away the values v and z after the coin has been 
validated and accepted, v would directly identify Alice since it is her public key and 
its connection with her can be found from a suitable CA. More obscurely, the value 
z, if acquired by the bank, can also be used to derive v. This is because of the 
following congruence: < 

v! = zlc? (mod p) (9) 
Once v* is known, it is easy to reveal v as: 

v = (v* mod p) where ed = 1 (mod p-1) (10) 

15 The bank has e to compute d above. This is analogous to a broken RSA algorithm 
where the factors of the modulus are known. Without giving these values to the bank, 
it is infeasible for the bank to find who has spent the coin. Brute-force searching 
through the public-key space for matching values g(v)oxf(x) (here, using f(x) is to 
check if a candidate result of Equation (5) can be hashed to f(x) in Coin) is 

20 computationally infeasible (the public-key space is vast) unless the bank can acquire a 
sufficiently large number of public keys of the users in the system (which should 
form a trivially small subset of the whole public-key space). This can be prevented by 
implementing the certification authorities that do not permit downloading public keys 
or certificates. Normal CA's should disallow such an abuse. 

25 

Now assume that the bank sees duplicated copies of the coin pseudonym C. This may 
be as a result of either (i) Alice's double spending, or (ii) the merchant's replay, or 
(Hi) a collusion between Alice and the merchant. 

30 In the first case (i), Alice double spends. It has been analysed that the differences in 
either merchdntjd or timestamp will result in two pairs of (e, y) and (e\ y') where e 
• e' (mod tf), and hence y * y', with an overwhelming probability, these two pairs 
will be sufficient for the bank to discover Alice's private key s using Equation (6), 
and further obtain her public key v from Equation (1). The bank can verify the 

35 correctness of the revealed public key by checking if it can be hashed to g(v) in Coin. 
(An incorrectness indicates a collusion between Alice and the merchant and this will 
be dealt with in Case (iii).) Such an identification is effective in the following 
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scenario. The bank can simply show the double spender's private key to the 
appropriate public-key certificate authority; the associated public-key certificate will 
be revoked instantly and unconditionally. Thus, no matter how small amount of 
money (even a single penny) is double spent, there are no possibly expensive legal 
5 requirements for the bank to comply regarding the revocation of the certificate in 
question. This identification method is therefore particularly suitable for 
micro-payment transactions. The method also strongly deters double spending: a new 
certificate for a new pair of public/private keys for an identified double spender can 
be made sufficiently expensive so that the price far outweighs the benefit of double 
10 spending the low-value coins. 

Note that Alice cannot use different key pairs (certified or not) to sign different 
spending signatures on the same coin pseudonym (try to double spend without 
disclosing her identity). This is because the merchant will only accept a signature that 

15 can be verified using the public key that can be hashed to the value g(v) in Coin. 
Similarly, Alice cannot use a wrong PSG to create a spending signature because the 
merchant will only accept one that can be hashed to the value/fr; in Coin. Permitting 
a spender to use incorrect public keys or incorrect PSG 1 s will lead to identifying the 
merchant as colluding with the double spender. Various cases of such collusion will 

20 be discussed in Case (iii). 

In the second case (ii), the merchant double deposits. If Alice does not double spend, 
then the merchant cannot double deposit a coin received from Alice where the 
different copies of coin-deposit in data set (8) have different yet valid spending 
25 signatures of Alice. Clearly, this is due to the inability to forge Alice's spending 
signature. Thus, the possibility for the merchant to double deposit a coin is confined 
to the following way: he simply replays the coin-deposit in data set (8) with identical 
data. It is easy for the bank to discover the replay and thereby only one instance of 
deposit will be redeemed. 

30 

Note that the merchant is required to sign the coin-deposit digitally in the data set (8). 
Therefore, depositing incorrect or gibberish data as spending signatures in order to 
achieve double deposit will lead to identifying the merchant as malicious. In Case 
(iii), cases will be seen of identifying malicious merchants. 

35 

In the third case (iii), Alice and the merchant collude. A collusion will make sense 
only if it does not lead to identifying Alice and at the same time it lets the merchant 
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deposit coins with consistent and non-identical spending signatures. 

It seems that in order to achieve the above, the merchant has to permit Alice to use 
incorrect keys (uncertified or not matching g(v) in Coin), or incorrect PSG's, to sign 
5 the spending signatures. For instance, in the case of permitting using incorrect keys, 
a coin can be double spent by a person who has different (certified or not) key pairs, 
or by different people (e.g. members in the same family). 

In these circumstances, upon seeing the duplicated coin pseudonym C, the bank's 
10 computation using Equation (6) will not correctly reveal Alice's private key. In an 
overwhelming probability, the revealed key will not belong to anybody (probability 
see below). For instance, let two spending signatures (e, y) and (e\ y') have been 
created with the use of two different private keys s, and s ; , respectively. Then, using 
Equation (6) will result in the following value: 

15 

s' = ((s,e - s*') I (e - e')) (mod q) 

Similarly, if the merchant permits Alice to use incorrect PSG's which are mapped 
from two different SSG's r, and r,, then Equation (6) will not disclose Alice's true 
20 private key either, but 

s' = (((/> - r, + s(e - e')) I (e - e')) (mod q) 

Other wrong forms of "private keys" can also be expected from mixed uses of wrong 
25 keys and wrong PSG's. Let v' be the matching "public key" computed from Equation 
(1) using s\ Then, in an overwhelming probability, v' will be found to have not been 
certified to anyone. The probability that v' happens to be someone's public key is 
equal to that of having correctly guessed someone's private key. 

30 If duplicated coin-deposits with different spending signatures have been deposited 
from the same merchant, then he is certainly malicious because either he has used 
incorrect public keys (cannot be hashed to g(v) or uncertified), or has permitted the 
use of incorrect PSG's during the time of verifying the spending signatures. 

35 If duplicated coin-deposits with different spending signatures have been, deposited 
from different merchants, then, at least one of the merchants is malicious and needs 
to be identified (e.g. Alice properly spends a coin with an honest merchant and then 
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double spends the same coin with collusive one). In such a situation, the CA has to 
be approached for decrypting the values E(z) that have been deposited from the 
respective merchants* With the decrypted data, the bank has sufficient data to 
differentiate an honest merchant from malicious ones. An honest merchant is related 
5 to a quantity z which can be hashed to f(x), and can be used to compute a correctly 
certified public key v (using Congruence (9) and Equation (10)) that can be hashed to 
g(v). Any quantity z not satisfying either of these two tests identifies a malicious 
merchant. The merchant cannot be framed because he has digitally signed the 
coin-deposit. 

10 

Note that when the CA is used, the identity of the spender becomes known to the 
bank. However, the bank cannot abuse this method with a true intention to identify a 
nori-double-spender (e.g. to claim falsely a double spending) because the CA will 
demand the bank demonstrate a merchant to be malicious whenever the CA is 
15 approached to decrypt E(z). The bank itself will be considered as malicious if at the 
end it cannot prove a merchant to be malicious. 

It is interesting to point put that, as long as a coin is not double spent or double 
deposited, the use of incorrect public keys or PSG's or handing in gibberish spending 
20 signatures will not be discovered. Indeed, here, the bank need not be concerned of 
anything other than double spending. 

To this end, we see that the merchant is unable to help Alice to double spend. 

25 Note that in the rare case of double spending achieved by a collusion between Alice 
and the merchant, the use of CA for decrypting the message E(z) seems to add a new 
role (or new burden) to CA. Nevertheless, this seemingly new role is in fact covered 
by the current services of CA's. This is because, when a collusion occurs, the key 
certificates of the responsible must be revoked anyway and the revocation is clearly 

30 part of the services of the CA's under the existing definition. A CA will never be 
approached if it is not requested to revoke a certificate. 

As in Schnorr's scheme, the security relies on the difficulty of searching for 
collisions in hash functions. If Alice can prepare collisions between different PSG's 
35 such that/fol =f(x 9 )> then she can double spend a coin using these two PSG's 

without being identified. Note that searching for collisions for different PSG's should 
start from searching for different SSG's (i.e., Alice must know different r* r' that 
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satisfy/fif modp) = f((f mqdpj; the exponentiation makes the search much harder 
than is usual for preparing hash-function collisions. 

There now follows a description of specific example protocols for Alice to pay cash 
5 coins in arbitrary denominations to various merchants, and for merchants to deposit 
coins to the bank. 

Each of the principals, Alices, various merchants A/„ M 2$ .... and the bank B is 
equipped with public/private key pairs and each of the public keys are properly 
10 certified to their owners by a well-known CA. So, each principal can recognise the 
public key of another principal. In particular, Alice's key pair is in the form of 
Schnorr's signature scheme described above. 

During a withdrawal time Alice constructs a chain of coins C ; , C 2 C a from the 

15 bank B by running an anonymous cash withdrawal protocol. These coins are 

constructed such that once they are in the hands of Alice, the bank no longer has any 
link between Alice and them. Such an anonymous cash withdrawal can be achieved 
by using Chaum's blind signature technique mentioned above. 

20 The structure of these coins follows that of the "Payword" technique expounded by 
Rivest and Shamir, or alternatively attributes to Lamport's original password 
identification technique (also known as the "S/Key" technique). A secure one-way 
hash function, h( J, is used to hash a secret number repeatedly for n times. Let C n be 
a secret number chosen by Alice. The chain of coins is constructed as follows: 

25 

C { ± h(C t +t) for i = 0, 1,2, n-l (11) 

She also chooses the first SSG r x and computes the respective PSG jc /t and lets B sign 
the pseudonym Q: 

30 

Sig B (C 0t g(v)J( Xl ), n) (12) 

Here, C 0 is called a "pseudonym-top"; it is not a coin. On the other hand, Q 
(1 s i s n) are n coins. The signature (12) shows that by signing the pseudonym-top 
35 C 0 , the bank has essentially signed all of the n coins. These coins are said to be under 
the pseudonym-top Q. The hashed values g(v) and f(x t ) have also been signed by the 
bank. So, the correct use of these coins can be verified later by a merchant using the 
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public key v and the first PSG x,. Note that, the blinded withdrawal procedure need 
not be based on using the public key v. 

Now Alice can start to spend coins. Starting with an initial payment of / coins to 
5 (I si m) a. first merchant Af„ the idea is to disclose the coin C, to M,. The coin C, 
will be called the "bottom-coin. " The merchant can verify the validity of the coins 
between the pseudonym-top and the bottom-coin by recursively hashing the 
bottom-coin Q for i times (see formula (11)). The computation will finally result in 
the pseudonym-top C 0 . To this end, the signature of the bank on the pseudonym-top 

10 can be verified (see (12)). However, the merchant will only accept these coins 

provided that Alice has also correctly signed the pseudonym-top using the one-time 
signature scheme that was described previously. Alice must generate the signature 
with the use of a PSG that can be hashed \of(x,). In addition, Alice must also 
generate a second SSG r 3 and send the hashed value of the second PSG f(xj to the 

15 merchant. The usage of the second PSG will be clear in a moment. A nice feature in 
Schnorr's scheme is that all of the SSG, PSG pairs can be pre-computed by the signer 
before the signing time. Thus, there will be no problem for Alice to prepare these 
pairs for future use. 

20 Upon acceptance of these i coins, the merchant M, should digitally sign the 

bottom-coin C, together with the hashed value/fx^, i.e. M, should send message 
Si 8Hi(Ci,f(Xz), (n - i)) back to Alice. This signature will serve the same function as 
the bank's signature for the pseudonym-top in (12). Namely, Alice can use it to 
spend the rest of the coins C f+ , C„ by using Q as a new top. For this 

25 reason, the term "current-top" will be used to refer to C,. By combining the 
bottom-coin with a PSG, the bottom-coin is turned into a current-top. Now this 
quantity can no longer be spent as a coin. Later, the merchant M, can use Q, C, to 
redeem / coins from the bank B as will be described in more detail below. 

30 Describing now a general setting, suppose Alice has spent / (j < n) coins to k - 1 

previous merchants M„ M 2 M k _, (some or all of them may be the same 

merchant) and she now holds the data Sig^fq, f( Xk ).(n -j)), i.e. the current-top and 
the hashed value of a PSG usable for the next payment. Here, M k ., is the merchant 
with whom Alice has shopped most recently. Under this general setting, we will 

35 specify the payment protocol with which Alice pays i coins to the next merchant M t 
for k > 0. These / coins are under the current-top C } . Note that in the above 
description of the initial payment, we have described a special case where j = 0, 
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k = 1 and M 0 = B. 

Payment A - Af,: gM>f(x t ), n), Sig^fqjfxJ, (n -j)), 

Cert(M^ f P^), C} + „ i, timestamp, e kf y kt f(x M h 
5 Cert(AticeJd> v) 

Here e k = h(C j9 M ki timestamp,f{x^) and y k = fa + se k mod tfj. Upon receipt of this 
payment message, the merchant M k will first verify the spending signature on the 
current-top C r This is by computing z k from Equation (5) as follows: 

10 

z k = ftfV mod p) 

and checking if 

15 e k = h(Cj> M k , timestamptffct)) 

If the equation holds, the merchant will further check whether the spending signature 
has been correctly created. This is to check whether the public key v that he has used 
in verifying the spending signature can be hashed to g(y) and the quantity z k can be 

20 hashed to/fr^. Here g(v) has been signed by the bank in the pseudonym-top, and 
f(xj has been signed by the previous merchant M kml in the current-top. The validation 
of such correctness will be in conjunction with the validation of the coins between the 
current-top and the bottom-coin. The merchant will perform the validation by 
repeatedly hashing the bottom-coin C J+i for j times to reach the current-top C Jf and 

25 further hashing it for another j times to reach the pseudonym-top C 0 followed by 
verifying the bank's digital signature. In this scheme, each time Alice spends coins 
under the current-top, she is required to sign the current-top. Thus, she cannot double 
spend even a single coin under each current-top. 

30 If everything goes well, these / coins will be accepted. If there are still unspent coins 
left under the bottom-coin C^ iy then there is a need to make change. In such a case, 
the merchant M k should send the following message back to Alice: 

Change M k - A: Sig m (Cj^f(x k ^) f (n i)), Cert{M k% P M) ) 

35 

With the signed data in the message "Change", the bottom-coin C Jt¥i becomes the new 
current-top and Alice can further spend the rest of the coins under it. 
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By recursively hashing the quantity C„ in the construction of coins, we use hash 
function h( J to serve the role of a counter. These hashed quantities are not worth any 
value if they are not properly signed with correct spending signatures. Therefore, 
some usually required hash function properties, such as non-invertibility, 
collision-resistance, etc, are not essentially required here (orh(). In particular, the 
issue of information entropy loss due to repeatedly hashing a piece of data for n 
(ji can be a large number) times need not be a concern here. Being able to invert h( ) 
does not lead to an ability to spend the revealed values as coins if one cannot 
correctly generate a spending signature. 



Note that although the scheme lets a merchant generate a new current-top (by 
combining a new usable PSG and the bottom-coin with a digital signature), this does 
not mean that a subsequent merchant has to trust any previous merchant in that he has 
integrated a good usable PSG with the current-top. The usability of the PSG can be 
verified by the next merchant who is to validate some coins under the current-top. 
Alice has freedom to choose any PSG she likes. It is purely Alice's interest to let 
each merchant combine a good PSG into the current-top. Using an old PSG will risk 
disclosing her private key, whereas using a bad PSG (e.g. with an unknown SSG), 
Alice will be unable to sign the spending signatures correctly for the rest of the coins; 
20 namely, the coins under the current-top will be wasted. 

It will further be seen that no merchant is able to help Alice by creating for her 
different copies of current-tops which are combined with different usable PSG's. The 
merchant M k can redeem the value of the / coins from the bank B by depositing the 
25 following data: 

Deposit M k -B: Sfg^gM/frAaug^^jfrj^.j,). 

Cert(M t .„ P m . t ), Sig Uk (C I+i , f(x t+l ). (n-j- i)), 
Cert(M kt P Mk ) t timestamp, e k , y k , EfxJ 



These data are analogous to the coin-deposit in (8) above. The signature of the 
previous merchant on the current-top q is needed in order to allow the current 
merchant M k to correctly redeem / coins. The merchant M k cannot redeem coins 
above the current-root (e.g. if he has intercepted the message "Deposit" sent from the 
previous merchant M w ) without being detected. The bank will eventually find that 
M k ., and M k claim the same coins where the spending signature for the "current-top" 
above these coins does not support M k (a wrong merchant id in the spending 
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signature). 

Upon receipt of the message "Deposit", the bank will check duplication of the coins 
between the current-top Cj and the bottom-coin C y+I , If any coin C,forj * I z Q + i) 
5 is found in the database, a fraud has been detected. The bank can differentiate double 
spending from double depositing, and deal with these frauds accordingly (see below). 
If everything is correct, it will credit the merchant and archive some of the data in the 
coin-deposit. Note that for hashed values as coins, only those that have been signed 
by the spender and merchants (i.e. each current- top) need to be archived against 
10 fraud. 

The merchants entitlement to make a signature that combines a bottom-coin with a 
hashed PSG (hence turning that bottom-coin into a new current-top) does not mean 
that he is able to help Alice to make many "current-tops" that are combined with 

15 different usable PSG's. Assume that the merchant M k helps Alice by making the 
following two different "current-tops" to be viewed by subsequent merchants: 
SigMk(Cj+of(x), (n -y - and Sig Mt (C JH ,f(x')> (n-j- 1))\ where x *x' and / may or 
may not be equal to L Notice that for this help to make sense, Alice must not be 
asked to make more than one spending signature on any current-top of these two 

20 coins; in other words, although these two signatures form two bottom-coins viewed 
by the merchant M k , he must not deposit both of them because their common 
current-top will identify him to be double depositing. The intention of this help is to 
let Alice use these different "current-tops" later without disclosing her private key 
(because of different PSG's used, even if / = i). However, the two subsequent 

25 merchants (possibly including M k himself) who receive coins under these two 

"current-tops" will hand them in as the second signature chunk in their respective 
messages "Deposit." This is equivalent to performing double deposit by the merchant 
M k . Namely, if the merchant helps Alice to double spend in this way, the deposit data 
from other merchants will reveal his identity. 

30 

Having described an example of the invention, the advantages of the invention, or at 
least of the example thereof, can be summarised as follows: 

(a) Spender's anonymity: as long as the spender does not double spend, the bank 
35 does not know who has spent the money. However, this is not a strong sense of 
untraceability because a collusive merchant can provide the bank with the spender's 
identity. It is believed that this weak sense of anonymity will be acceptable by many 
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users as they will regard the convenience of sending money over the Internet to 
outweigh the extremely small probability of collusions between a bank and a large 
number of merchants. People's attitude toward sending money over the Internet is 
likely to change. For instance, sending a few cents or a couple of dollars over the 
5 Internet will no longer be considered as "dangerous** as sending one's credit-card 
number. 

(b) Identifying double spender with strong proof. The identification is effective; 
the deterrence on double spending is strong; it is simple for the bank to require 

10 revocation of the double spender's public-key certificate. 

(c) Using no on-line banks for making payment. 

(d) Being independent of using tamper-resistant devices. Thus, the technique can 
15 readily be deployed over today's Internet. 

(e) Coin sub-divisible to arbitrary denominations. For instance, a new chain of 
coins can worth 10 dollars with each coin worth 1 cent (i.e. n in the pseudonym-top 
is equal to 1,000). After Alice has sent the current-top to the merchant, she can 

20 continuously release the coins under it, until (s)he feels enough services/goods have 
been purchased. No further signature is needed for these coins. This is particularly 
suitable for web-based interactive information page purchase. 

(f) Small data size for coins. Paying a merchant with arbitrary number of coins 
25 (up to *), the message "Payment" can readily be organised within one kilobyte 

(including key certificates). It is believed that this size of data may well be smaller 
than the previous techniques for off-line cash coins independent of using smartcards. 
The storage of arbitrary number of coins uses the same data size as that in the 
"Payment" message. 

30 

(g) No need of interactive communications between purchaser and merchant. In 
fact, the message "Change" is needed only to give change. Thus, a payment can be 
made in a single email. 

35 Having described an example of the invention, it will be appreciated that many 

modifications may be made to it, and that it may have many other applications. For 
example, as explained above, if a spender double-spends, the bank can discover the 
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spender's private key s and public key v. It is therefore then possible for a fraudulent 
bank employee to spend the remainder of the spender's money, rather than having the 
spender's public-key certificate revoked. In order to deal with this, the example 
scheme may be modified as follows: 

(a) A spender has a first certified public key v as before, a second certified public 
key v', and two corresponding private keys s and s', respectively. 

(b) Referring to Figure 1 , a second SSG r' is chosen such that r' < q, and a 
second PSG x' is calculated such that: 

x' = ct mod p. 

(c) Referring to Figure 5, a third signature part e' is calculated such that: 

e' = h(C, merchant Jd, timestamp, x') 

i.e. based on x' as in Schnorr's scheme, rather that/fr 'j as in the main 
example described above. 

(d) A fourth signature part y' is calculated such that: 

y' = ffr' +s'e') mod q 

(e) The transmission which is required to be sent to Bob is in the form: 

Coin, merchant Jd, timestamp, e, y, e'.y', CertfAliceJd, v, v') 

i.e. also including the third and fourth signature parts e', y', and including the 
second public key v' in the public key certificate. It should be noted that, 
although the first public key v is integrated in Coin, the second public key v* 
is not. 

(f) Referring to Figure 6, Bob additionally calculates a second apparent PSG z' 
such that: 
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(g) Bob then carries out a fourth check as follows: 

e' = JifC, merchant Jd, timestamp, z') ? 

5 and if that check fails, then Coin is rejected as invalid in Step 70. 

In the case of a double spend, the bank employee may be able to ascertain the 
spender's first private key s as discussed in the main example, but will notbe able to 
ascertain the second private key s' and therefore not be able to misappropriate the 
10 remainder of the money. 
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CLAIMS 

1. A method of transmitting a message over a network from a sender to a 
5 receiver, comprising the steps of: 

taking a message (Coin) to be signed by the sender; 

signing the message into a digital signature (e, y) of the sender, the digital signature 
being generated as a function of that message using public and secret signature 
generators (x, r) of the sender, a private key (s) of the sender, and other publicly 
10 known values (a, p, q); and 

transmitting the signed message over the network to the receiver; 
characterised in that: 

the message to be signed by the sender incorporates a first value (f(x)) which is a first 
predetermined function (f( )) of the sender's public signature generator (x). 

15 

2. A method as claimed in claim 1, wherein the first predetermined function 
(f( )) is a secure one-way hash function. 

3. A method as claimed in claim 1 or 2, wherein the signature includes a second 
20 value (e) which is a second predetermined function (h( )) dependent on the first value 

(f(x)). 

4. A method as claimed in claim 3, wherein the second predetermined function 
(h( )) is a secure one-way hash function. 

25 

5. A method as claimed in claim 3 or 4, wherein the signature includes a third 
value (y) which is a third predetermined function of the secret signature generator (r), 
the second value (e), the private key (s) of the sender, and at least one (q) of the 
publicly known values. 

30 

6. A method as claimed in any preceding claim, wherein the message to be 
signed by the sender incorporates a fourth value (g(v)) which is a fourth 
predetermined function (g( )) of a public key (v) of the sender. 

35 7. A method of transmitting a message over a network from a sender to a 
receiver, comprising the steps of: 
taking a message (Coin) to be signed by the sender; 
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signing the message into a digital signature (e, y) of the sender, the digital signature 
being generated as a function of that message using public and secret signature 
generators (x, r) of the sender, public and private keys (v, s) of the sender, and other 
publicly known values (a, p, q); and 
5 transmitting the signed message oyer the network to the receiver; 
characterised in that: 

the message to be signed by the sender incorporates a fourth value (g(v)) which is a 
fourth predetermined function (g( )) of the public key (v) of the sender. 

10 8. A method as claimed in claim 6 or 7, wherein the fourth predetermined 
function (g( )) is a secure one-way hash function. 

9. A method of verifying a signed message received over a network, the signed 
message purporting to have been transmitted in accordance with the method of any of 

15 claims 1 to 6, or claim 8 when dependent on claim 6, comprising the steps of: 

calculating an apparent public signature generator (z) of the sender using the signed 
message, a public key (v) of the sender and other publicly known values (a, p); 
calculating a fifth value (f(z)) which is the first predetermined function (f( )) of the 
apparent public signature generator (z); and 

20 comparing the fifth value (f(z)) with the first value (f(x)) incorporated in the received 
signed message. 

10. A method as claimed in claim 9 when dependent directly or indirectly on 
claim 3, including the further steps of: 

25 calculating a sixth value (e) which is the second predetermined function (h( )) of the 
fifth value; and 

comparing the sixth value (e) with the second value (e) included in the received 
signature. 

30 11. A method as claimed in claim 9 or 10 when dependent directly or indirectly 
on any of claims 6 to 8, including the further steps of: 

calculating a seventh value (g(v)) which is the fourth predetermined function (g( )) of 
a public key (v) of the sender received over the network; and 
comparing the seventh value (g(v)) with the fourth value (g(v)) incorporated in the 
35 signed message. 

12. A method of verifying the public key of the sender of a signed message 
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received over a network, the signed message purporting to have been transmitted in 
accordance with the method of any of claims 6 to 8, comprising the steps of: 
calculating a seventh value (g(v)) which is the fourth predetermined function (g( )) of 
the public key (v) of the sender received over the network; and 
5 comparing the seventh value (g(v)) with the fourth value g(v) incorporated in the 
signed message. 

13. A method according to any preceding claim, wherein the message represents a 
sum of money. 

10 

14. An apparatus adapted to perform the method of any preceding claim. 
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